home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_1599 / 1569 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  3.0 KB
  1. Subject: some clues for the 110h4 problem?
  2. Date: Mon, 27 Jun 94 22:33:12 +0200
  3. From: Torsten Scherer <itschere@techfak.uni-bielefeld.de>
  4.  
  5.  Yeah, well, I'm not quite sure if this might help anyone, but I've tried
  6. to track down some of *my* (say: MP) problems with mint110h4, and what
  7. I've discovered is:
  8.  
  9.  MiNT itself can start every program from mint.cnf, including init. It does
  10. so by calling p_exec(0).
  11.  
  12.  Init can't start /bin/sh (the MiNTOS one) for the bootup scripts, when it
  13. tries to launch it with p_fork/p_exec(200), the child get's killed immediately
  14. (I see from the PID that it's the child) but successfully manages to start
  15. three gettys with p_vfork/p_exec(200). Note that the getty for the console
  16. is started first and the others afterwards!
  17.  
  18.  When I try to log into the console, the first getty crashes after asking for
  19. the login name. The next attempt goes through to passwd, which does *not*
  20. crash when starting my shell, the Michael Hohmuth port of tcsh 6.0.3.
  21.  
  22.  This one can be repeated on any tty. The first getty crashes, the second
  23. one goes through. If you log out and log in again immediately, the first
  24. one succeeds immediately. If you log out and start any other program on any
  25. other tty, so that the next getty will be loaded to another adress, the first
  26. attempt on the original tty will crash again. All this looks like the code
  27. for setting up some segment is broken, which needn't be called again if - by
  28. pure coincidence - the segment is already in memory at the same adress, and
  29. therefore doesn't break this time.
  30.  
  31.  Since *none* of these login tools was compiled with -mbaserel, *nor* has it
  32. got the sticky bit set, the `remaining in memory' can only be a bug.
  33.  
  34.  The /bin/sh (*not* compiled with -mbaserel) seems to start every program -
  35. either in background or in foreground - with p_fork/p_exec(200) and crashes
  36. every time, even if you try to trigger the above mentioned effect and try
  37. to start the same program repeatitively.
  38.  
  39.  The tcsh (compiled with -mbaserel, but without sticky bit) starts programs
  40. in the foreground with p_vfork/p_exec(200) and doesn't produce any problems
  41. then. When it tries to start a program in the background (using p_fork/
  42. p_exec(200)) the forked child immediately crashes.
  43.  
  44.  Each time the problem is triggered by a p_fork() with a subsequent p_exec()
  45. and each time the *child* crashes *after* it's got its PID, but *before* it's
  46. got its name.
  47.  
  48.  That's where I'm standing now, a bit tired, at 10:30pm local time. Can there
  49. please somebody else who's more familiar with that parts of MiNT have a
  50. closer look at it?
  51.  
  52.  Anybody who still thinks this is a compiler bug (mine: bmgcc233p2) may feel
  53. free to send me a -DONLY030 binary of the unmodified 110h4 code compiled with
  54. his/her preferred compiler to test it and I promise never to mention their
  55. names for `illegally' copying binaries of MiNT. :-)
  56.  
  57. good night,
  58. TeSche
  59. -- 
  60. Torsten Scherer (TeSche, Schiller...)
  61. Faculty of Technology, University of Bielefeld, Germany, Europe, Earth...
  62. | Use any of "finger itschere@129.70.131.2-15" for adresses and more.|
  63. | Last updated: 14. April 1994.|
  64.